In high security operating environments, the US National Institute of Standards and Technology (NIST) specifies in FIPS PUB 140-2, “Security Requirements For Cryptographic Modules,” for security levels 3 and 4 that critical security parameters (CSP) such as authentication data, passwords, PINs, CSPs, biometric samples, secret and private cryptographic keys be entered into or output from a cryptographic module in an encrypted form, generally using some form of physical and/or logical trusted path or secure messaging channel to prevent interception of the critical security parameters.
The cryptographic modules referred to in this specification include hardware based security devices such as security tokens, smart cards, integrated circuit chip cards, portable data carriers (PDC), personal security devices (PSD), subscriber identification modules (SIM), wireless identification modules (WIM), USB token dongles, identification tokens, secure application modules (SAM), hardware security modules (RSM), secure multi-media token (SMMC), trusted platform computing alliance chips (TPCA) and like devices.
Attempts at providing a physical trusted path include the use of cryptographic hardware devices installed between input devices such as the keyboard and possibly the mouse. An example of such a cryptographic interface device is disclosed in U.S. Pat. No. 5,841,868 to Helbig. However, the hardware expenditures and added administrative burden greatly increases the cost of the computer system.
In another approach, U.S. Pat. No. 4,945,468 to Carson, et al., a trusted path is generated by providing a new virtual terminal window which allows secure entry of CSPs. The new virtual terminal window is effectively isolated from other running processes. This method is a reasonably secure approach but does not extend the trusted path to peripheral security devices such as cryptography modules, cryptographic modules and biometric scanners.
In yet another approach, US patent application 2002/0095587 to Doyle, et al. discloses a wireless SSL or equivalent connection which utilizes negotiated time-limited cryptography keys to maintain a chain of trust between interconnected security devices. However, the mechanism disclosed relies heavily on multiple public key cryptography key pairs which is difficult to maintain and may reduce overall performance due to relatively slow transaction processing when employed using a smart card. In addition, negotiation of time-limited cryptography keys relies on devices containing a system clock for changing of cryptographic keys. Smart cards and like devices do not include system clocks and thus cannot be part of the negotiated key exchange.
Cryptographic mechanisms are available in the relevant art which could be adapted to encrypt an incoming CSP with a cryptographic key for secure transport through a host and eventual decryption by a security executive installed within the cryptographic module. However, the cryptographic mechanism employed by the host must provide a sufficient level of security to prevent interception of the cryptographic keys used in encrypting the CSP and furthermore limits vulnerability to a replay type attack.
Another common vulnerability in the relevant art relates to the lack of ability to bind a CSP to a session, which potentially allows an unlocked cryptographic module to accessed by an unauthorized entity. To address this potential vulnerability, the CSP is typically cached or stored and presented by software to the cryptographic module each time access is required. The cached or stored CSPs are likewise vulnerable to interception or compromise by an authorized entity.
Therefore, it would highly advantageous to provide a secure CSP transport system which limits an intruder's ability to intercept a cryptographic key, is relatively invulnerable to a replay type attack, minimizes requests for user input of CSPs already provided within a session and does not store or otherwise cache a CSP.